fix(docs): refresh trunk version pins to Cozystack v1.6.3 - #618
Conversation
✅ Deploy Preview for cozystack ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Advanced Run ID: 📝 WalkthroughWalkthroughThe next release manifest updates Cozystack from 1.5.0 to 1.5.3 and Talos from v1.13.0 to v1.13.6. ChangesNext release version pins
Estimated code review effort: 1 (Trivial) | ~2 minutes Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
Full details: Title checkExplanation The title refers to refreshing trunk version pins, but it specifies Cozystack v1.6.3. The change updates Cozystack to v1.5.3 and Talos to v1.13.6. The ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request updates the Cozystack version to 1.5.3 and the Talos version to v1.13.6 in the data/versions/next.yaml file. There are no review comments, and I have no feedback to provide.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
myasnikovdaniil
left a comment
myasnikovdaniil
left a comment
There was a problem hiding this comment.
Request changes — one correctness issue.
The Talos half is correct and worth landing: talos: v1.13.6 / talos_minor: v1.13 matches the installer profile on cozystack/cozystack@main (packages/core/talos/images/talos/profiles/installer.yaml). But the Cozystack pin is bumped to v1.5.3, which is still a draft release (isDraft: true, publishedAt: null): I verified the exact asset URLs the next/ install docs generate (e.g. .../releases/download/v1.5.3/cozystack-crds.yaml) return 404 on v1.5.3 but 200 on v1.5.2 (the current latest published release). Merging as-is hands readers copy-paste install commands that 404 until v1.5.3 is actually cut. Pin to v1.5.2 (suggestions inline), or hold this PR until v1.5.3 is published.
| # Cozystack release the docs are pinned to. | ||
| cozystack_version: "1.5.0" # bare, as used by `helm --version` | ||
| cozystack_tag: "v1.5.0" # v-prefixed, as used in GitHub URLs | ||
| cozystack_version: "1.5.3" # bare, as used by `helm --version` |
There was a problem hiding this comment.
v1.5.3 is a draft release (isDraft:true, publishedAt:null) — helm --version 1.5.3 and the GitHub download URLs built from this pin fail publicly until it's published. Latest final is v1.5.2:
| cozystack_version: "1.5.3" # bare, as used by `helm --version` | |
| cozystack_version: "1.5.2" # bare, as used by `helm --version` |
There was a problem hiding this comment.
Fixed in 89518d1, with 1.6.3 instead of 1.5.2: after the rebase v1.6.3 is the latest published release.
| cozystack_version: "1.5.0" # bare, as used by `helm --version` | ||
| cozystack_tag: "v1.5.0" # v-prefixed, as used in GitHub URLs | ||
| cozystack_version: "1.5.3" # bare, as used by `helm --version` | ||
| cozystack_tag: "v1.5.3" # v-prefixed, as used in GitHub URLs |
There was a problem hiding this comment.
Same issue — this tag feeds real download commands in the trunk install docs (install/kubernetes/generic.md, install/talos/iso.md, install/providers/oracle-cloud.md), all of which 404 against the draft:
| cozystack_tag: "v1.5.3" # v-prefixed, as used in GitHub URLs | |
| cozystack_tag: "v1.5.2" # v-prefixed, as used in GitHub URLs |
There was a problem hiding this comment.
Fixed in 89518d1 with v1.6.3. The asset URLs the trunk pages build from this tag return 200.
IvanHunters
left a comment
IvanHunters
left a comment
There was a problem hiding this comment.
Reviewed as a docs pass. The Talos half is correct and could land on its own; the Cozystack version pin is the blocker.
- data/versions/next.yaml pins
cozystack_version/cozystack_tagto1.5.3/v1.5.3, but that release is still a draft (verified today: the release is unpublished and the docs-generated assetreleases/download/v1.5.3/cozystack-crds.yamlreturns 404, while v1.5.2 returns 200). Everynext/install page would hand readers copy-paste commands that 404. Suggest pinning tov1.5.2(current latest published), or holding until v1.5.3 is actually cut. - The Talos pin
talos: v1.13.6/talos_minor: v1.13matches installer.yaml on cozystack/cozystack main; that half is good to go. If split, the Talos bump can merge immediately. - This file is autogenerated (
make update-versions); the durable fix (refreshingnext/in the release job) is correctly noted as a follow-up in the PR body.
Docs update for release `v1.6.0` — the equivalent of what `update-website-docs` in cozystack/cozystack's `tags.yaml` normally opens. Run by hand because that workflow was never triggered for the `v1.6.0` tag: `v1.6.0` is the first stable tag created through the rc→stable promote flow, and the tag push produced no workflow run. Produced by `make release-next RELEASE_TAG=v1.6.0` followed by `make update-all BRANCH=release-1.6.0 RELEASE_TAG=v1.6.0`, with the commit scoped to `content/`, `hugo.yaml` and `data/versions/` exactly as the workflow stages it. `next/` is unchanged. One edit beyond the generated output: `data/versions/v1.6.yaml` pins `talos: "v1.13.6"` instead of the `v1.13.0` it inherited from `next.yaml`. Cozystack v1.6.0 ships Talos v1.13.6 — both `packages/core/talos/images/talos/profiles/installer.yaml` on `release-1.6` and the v1.6.0 changelog agree — but `make update-all` skips `update-versions` for a released version, so the snapshot froze the stale trunk pin. Shipping it unchanged would have pointed v1.6 readers at a Talos release predating the KVM guest-escape CVE fixes that bump was made for. `next.yaml` itself is deliberately untouched; #618 owns that refresh.
The next/ trunk still pinned Cozystack v1.5.0 and Talos v1.13.0, while the latest published release is v1.6.3 and the installer profile ships Talos v1.13.6. Every install page under next/ therefore handed readers download URLs and a Helm chart version from the previous minor release, plus a Talos version older than the one Cozystack installs. Nothing refreshes these pins on its own. update-versions only runs when DOC_VERSION is next, and every release path resolves it to a released version instead: a patch release routes to the existing vX.Y directory, and on a new minor release-next creates that directory before update-all runs. So the release workflow never regenerates the trunk, and the pins drift until someone runs the generator by hand, as here. Regenerated with make update-versions. Assisted-by: LLM Signed-off-by: Aleksei Sviridkin <f@lex.la>
551212e to
89518d1
Compare
✅ Deploy Preview for cozystack ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
Aleksei Sviridkin (lexfrei)
changed the title
|
myasnikovdaniil IvanHunters v1.5.3 was indeed a draft. The PR sat long enough that 1.5.x is no longer the target, so instead of v1.5.2 I rebased onto main and regenerated the pins in 89518d1. The trunk now points at v1.6.3, the latest published release. Its download assets return 200 and the |
IvanHunters
left a comment
IvanHunters
left a comment
There was a problem hiding this comment.
Verdict
LGTM
The three pins are what hack/update_versions.sh produces against upstream today, and everything they resolve to at v1.6.3 is published: the release is final and not a draft, the operator manifests and the ISO/nocloud/raw assets return 200, and cozy-installer 1.6.3 pulls from GHCR. Talos v1.13.6 is the version packages/core/talos/images/talos/profiles/initramfs.yaml pins at the v1.6.3 tag and on main alike, so talos_minor: v1.13 still matches. No consumer of the four variables is left pointing at stale content.
Caveats
- The
talos.devlinks built fromtalos_minorare broken upstream, and this diff neither causes nor fixes that.v1.13is unchanged here, and 5 of 8 trunk URLs 404 against the live site after Sidero Labs moved their docs todocs.siderolabs.com:https://www.talos.dev/v1.13/learn-more/talosctl/,/talos-guides/install/talosctl/,/talos-guides/network/kubespan/,/learn-more/talos-network-connectivity/,/talos-guides/configuration/disk-management/.data/versions/v1.5.yamlandv1.6.yamlcarry the same value, so every released doc version is affected too. Worth its own issue. - The PR body's diagnosis holds up independently. In the documented new-minor flow,
make release-nextruns beforemake update-all, so by the timeupdate-versionsruns,DOC_VERSIONalready points at the freshly createdvX.Yrather thannext, and the target no-ops on a released version. Patch releases no-op the same way. That leavesnext.yamlrefreshed only when somebody runs the target by hand, which is what happened here. next.yamltracks two different refs and its own header says so:talos/talos_minorfollowcozystack/cozystack@main, whilecozystack_version/_tagfollow the latest final release tag. They agree today. Nothing holds them together ifmainmoves its installer pin before the next release is cut.
Follow-ups worth filing
- The
talos.dev404s, as a site-wide issue rather than something for this PR. - Running
update-versionsonnext/on its own cadence, or from the release job before promotion, which is the fix the PR body itself points at.
The v1.5.3 pin is gone: the trunk now points at v1.6.3, regenerated in 89518d1 and answered in the threads. Re-review requested; dismissing so the PR is not held by a stale state.
3 participants
The trunk docs point at old releases.
next/pinned Cozystack v1.5.0 and Talos v1.13.0, while the latest published Cozystack release is v1.6.3 and its installer ships Talos v1.13.6. So every install page undernext/gave readers download URLs and a Helm chart version from the previous minor release, and an older Talos than the one Cozystack installs.data/versions/next.yamlis regenerated withmake update-versions, no hand edits. I checked that the release assets the trunk install pages link to exist under v1.6.3 and that thecozy-installerchart 1.6.3 is published.The pins drifted because nothing refreshes them.
update-versionsonly does work whenDOC_VERSIONisnext, and every release path resolves it to a released version instead. A patch release routes to the existingvX.Y/directory. On a new minor,release-nextcreates that directory beforeupdate-allruns. So the release workflow snapshots the trunk intovX.Y.yamland never regenerates the trunk itself. The pins will drift again unless the generator runs on a schedule or the release job refreshesnext/before promoting it.